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Abstract 


This memo discusses and defines terms associated with performance 
benchmarking tests and the results of these tests in the context of 
frame relay switching devices. 


I. Background 
1. Introduction 


This document provides terminology for Frame Relay switching devices. 
It extends terminology already defined for benchmarking network 
interconnect devices in RFCs 1242, 1944 and 2285. Although some of 
the definitions in this memo may be applicable to a broader group of 
network interconnect devices, the primary focus of the terminology in 
this memo is on Frame Relay Signaling. 


This memo contains two major sections: Background and Definitions. 
The background section provides the reader with an overview of the 
technology and IETF formalisms. The definitions section is split 
into two sub-sections. The formal definitions sub-section is 
provided as a courtesy to the reader. The measurement definitions 
sub-section contains performance metrics with inherent units. 


The BMWG produces two major classes of documents: Benchmarking 
Terminology documents and Benchmarking Methodology documents. The 
Terminology documents present the benchmarks and other related terms. 
The Methodology documents define the procedures required to collect 
the benchmarks cited in the corresponding Terminology documents. 
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TE% 


For the purposes of computing several of the metrics, certain textual 
conventions are required. Specifically: 


1) The notation sum {i=1 to N} A_i denotes: the summation of N 
instances of the observable A. For example, the set of observations 
{1,2,3,4,5} would yield the result 15. 


2) The notation max {I=1 to N} A_i and min {I=1 to N} A_i denotes: 
the maximum or minimum of the observable A over N instances. For 
example, given the set of observations {1,2,3,4,5}, max {i=1 to 5} = 
5 and min {I=1 to 5} = 1. 


The terms defined in this memo will be used in addition to terms 
defined in RFCs 1242, 1944 and 2285. This memo is a product of the 
Benchmarking Methodology Working Group (BMWG) of the Internet 
Engineering Task Force (IETF). 


Existing Definitions 


RFC 1242, "Benchmarking Terminology for Network Interconnect 
Devices", should be consulted before attempting to make use of this 
document. RFC 1944, "Benchmarking Methodology for Network 
Interconnect Devices", contains discussions of a number of terms 
relevant to the benchmarking of switching devices and should also be 
consulted. RFC 2285, "Benchmarking Terminology for LAN Switching 
Devices", contains a number of terms pertaining to traffic 
distributions and datagram interarrival. For the sake of clarity and 
continuity this RFC adopts the template for definitions set out in 
Section 2 of RFC 1242. 


Definitions 


The definitions presented in this section have been divided into two 
groups. The first group is formal definitions, which are required in 
the definitions of the performance metrics but are not themselves 
strictly metrics. These definitions are subsumed from other work 
done in other working groups both inside and outside the IETF. They 
are provided as a courtesy to the reader. 
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1. Formal Definitions 
1.1. Definition Format (from RFC1242) 
Term to be defined. 
Definition: The specific definition for the term. 


Discussion: A brief discussion of the term, its application and any 
restrictions on measurement procedures. 


Specification: The working group and document in which the term is 
specified. Listed in the references. 


1.2. Frame Relay Related Definitions 
1.2.1. Access Channel 


Definition: Access channel refers to the user access channel across 
which frame relay data travels. Within a given DS-3, T1 or El 
physical line, a channel can be one of the following, depending of 
how the line is configured. Possible line configurations are: 


A. Unchannelized: The entire DS-3/T1/E1 line is considered a channel, 
where: 


The DS-3 line operates at speeds of 45 Mbps and is a single channel. 
The T1 line operates at speeds of 1.536 Mbps and is a single channel 
consisting of 24 T1 time slots. The El line operates at speeds of 
1.984 Mbps and is a single channel consisting of 30 DSO time slots. 


B. Channelized: The channel is any one of N time slots within a given 
line, where: 


The T1 line consists of any one or more channels. Each channel is 
any one of 24 time slots. The T1 line operates at speeds in 
multiples of 56/64 Kbps to 1.536 Mbps, with aggregate speed not 
exceeding 1.536 Mbps. The El line consists of one or more channels. 
Each channel is any one of 31 time slots. The El line operates at 
speeds in multiples of 64 Kbps to 1.984 Mbps, with aggregate speed 
not exceeding 1.984 Mbps. 


C. Fractional: The T1/E1 channel is one of the following groupings of 
consecutively or non-consecutively assigned time slots: 


N DSO time slots (NX56/64Kbps where N = 1 to 24 DSO time slots per 
FT1 channel). 
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N El time slots (NX64Kbps, where N = 1 to 30 DSO time slots per El 
channel). 


Discussion: Access channels specify the physical layer interface 
speed of a DTE or DCE. In the case of a DTE, this may not correspond 
to either the CIR or EIR. Specifically, based on the service level 
agreement in place, the user may not be able to access the entire 
bandwidth of the access channel. 


Specification: FRF 
1.2.2. Access Rate (AR) 
Definition: The data rate of the user access channel. The speed of 


the access channel determines how rapidly (maximum rate) the end user 
can inject data into a frame relay network. 


Discussion: See Access Channel. 
Specification: FRF 


1.2.3. Backward Explicit Congestion Notification (BECN) 


Definition: BECN is a bit in the frame relay header. The bit is set 
by a congested network node in any frame that is traveling in the 
reverse direction of the congestion. 


Discussion: When a DTE receives frames with the BECN bit asserted, it 
should begin congestion avoidance procedures. Since the BECN frames 
are traveling in the opposite direction as the congested traffic, the 
DTE will be the sender. The frame relay layer may communicate the 
possibility of congestion to higher layers, which have inherent 
congestion avoidance procedures, such as TCP. See Frame Relay Frame. 


Specification: FRF 

1.2.4. Burst Excess (Be) 
Definition: The maximum amount of uncommitted data (in bits) in 
excess of Committed Burst Size (Bc) that a frame relay network can 
attempt to deliver during a Committed Rate Measurement Interval (Tc). 
This data (Be) generally is delivered with a lower probability than 


Be. The network treats Be data as discard eligible. 


Discussion: See also Committed burst Size (Bc), Committed Rate 
Measurement Interval (Tc) and Discard Eligible (De). 


Specification: FRF 
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1.2.5. Committed Burst Size (Bc) 
Definition: The maximum amount of data (in bits) that the network 
agrees to transfer, under normal conditions, during a time interval 


Tes 


Discussion: See also Excess Burst Size (Be) and Committed Rate 
Measurement Interval (Tc). 


Specification: FRF 
1.2.6. Committed Information Rate (CIR) 


Definition: CIR is the transport speed the frame relay network will 
maintain between service locations when data is presented. 


Discussion: CIR specifies the guaranteed data rate between two frame 
relay terminal connected by a frame relay network. Data presented to 
the network in excess of this data rate and below the Excess 
Information Rate (EIR) will be marked as Discard Eligible and may be 
dropped. 

Specification: FRF 


1.2.7. Committed Rate Measurement Interval (Tc) 


Definition: The time interval during which the user can send only 


Bc-committed amount of data and Be excess amount of data. In 
general, the duration of Tc is proportional to the "burstiness" of 
the traffic. Tc is computed (from the subscription parameters of CIR 


and Bc) as Tc = Bc/CIR. Tc is not a periodic time interval. 
Instead, it is used only to measure incoming data, during which it 
acts like a sliding window. Incoming data triggers the Tc interval, 
which continues until it completes its computed duration. 


Discussion: See also Committed Information Rate (CIR) and committed 
Burst Size (Bc). 


Specification: FRF 
1.2.8. Cyclic Redundancy Check (CRC) 
Definition: A computational means to ensure the accuracy of frames 


transmitted between devices in a frame relay network. The 
mathematical function is computed, before the frame is transmitted, 
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at the originating device. Its numerical value is computed based on 
the content of the frame. This value is compared with a recomputed 
value of the function at the destination device. See also Frame 


Check Sequence (FCS). 
Discussion: CRC is not a measurement, but it is possible to measure 
the amount of time to perform a CRC on a string of bits. This 
measurement will not be addressed in this document. 
Specification: FRF 

1.2.9. Data Communications Equipment (DCE) 
Definition: Term defined by both frame relay and X.25 committees, 


that applies to switching equipment and is distinguished from the 
devices that attach to the network (DTE). 


Discussion: Also see DTE. 
Specification: FRF 

1.2.10. Data Link Connection Identifier (DLCI) 
Definition: A unique number assigned to a PVC end point in a frame 
relay network. Identifies a particular PVC endpoint within a user’s 
access channel in a frame relay network and has local significance 
only to that channel. 
Discussion: None. 
Specification: FRF 

1.2.11. Data Terminal Equipment (DTE) 
Definition: Any network equipment terminating a network connection 
and is attached to the network. This is distinguished from Data 


Communications Equipment (DCE), which provides switching and 
connectivity within the network. 


Discussion: See also DCE. 


Specification: FRF 
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1.2.12. Discard Eligible (DE) 


Definition: This is a bit in the frame relay header that provides a 
two level priority indicator, used to bias discard frames in the 
event of congestion toward lower priority frames. Similar to the CLP 
bit in ATM. 


Discussion: See Frame Relay Frame. 
Specification: FRF 
1.2.13. Discardable frames 


Definition: Frames identified as being eligible to be dropped in the 
event of congestion. 


Discussion: The discard eligible field in the frame relay header is 
the correct -- and by far the most common -- means of indicating 
which frames may be dropped in the event of congestion. However, DE 
is not the only means of identifying which frames may be dropped. 
There are at least three other cases that apply. 


In the first case, network devices may prioritize frame relay traffic 
by non-DE means. For example, many service providers prioritize 
traffic on a per-PVC basis. In this instance, any traffic from a 
given DLCI (data link channel identifier) may be dropped during 
congestion, regardless of whether DE is set. 


In the second case, some implementations use upper-layer criteria, 
such as IP addresses or TCP or UDP port numbers, to prioritize 
traffic within a single PVC. In this instance, the network device 
may evaluate discard eligibility based on upper-layer criteria rather 
than the presence or absence of a DE bit. 


In the third case, the frame is discarded because of an error in the 
frame. Specifically, frames that are too long or too short, frames 
that are not a multiple of 8 bits in length, frames with an invalid 
or unrecognized DLCI, frames with an abort sequence, frames with 
improper flag delimitation, and frames that fail FCS. 

Specification: FRMIB 


1.2.14. Discarded frames 


Definition: Those frames dropped by a network device. 
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Discussion: Discardable and discarded frames are not synonymous. 

Some implementations may ignore DE bits or other criteria, even 
though they supposedly use such criteria to determine which frames to 
drop in the event of congestion. 


In other cases, a frame with its DE bit set may not be dropped. One 
example of this is in cases where congestion clears before the frame 
can be evaluated. 


Specification: DN 
1.2.15. Forward Explicit Congestion Notification (FECN) 


Definition: FECN is a bit in the frame relay header. The bit is set 
by a congested network node in any frame that is traveling in the 
same direction of the congestion. 


Discussion: When a DTE receives frames with the FECN bit asserted, it 
should begin congestion avoidance procedures. Since the FECN frames 
are traveling in the same direction as the congested traffic, the DTE 
will be the receiver. The frame relay layer may communicate the 
possibility of congestion to higher layers, which have inherent 
congestion avoidance procedures, such as TCP. See Frame Relay Frame. 


Specification: FRF 

1.2.16. Frame Check Sequence (FCS) 
Definition: The standard 16-bit cyclic redundancy check used for HDLC 
and frame relay frames. The FCS detects bit errors occurring in the 
bits of the frame between the opening flag and the FCS, and is only 
effective in detecting errors in frames no larger than 4096 octets. 
See also Cyclic Redundancy Check (CRC). 
Discussion: FCS is not a measurement, but it is possible to measure 
the amount of time to perform a FCS on a string of bits. This 
measurement will not be addressed in this document. 


Specification: FRF 


1.2.17. Frame Entry Event 


Definition: Frame enters a network section or end system. The event 
occurs when the last bit of the closing flag of the frame crosses the 
boundary. 


Discussion: None. 
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Specification: FRF.13 


1.2.18. Frame Exit Event 


Definition: Frame exits a network section or end system. The event 
occurs when the first bit of the address field of the frame crosses 
the boundary. 


Discussion: None. 
Specification: FRF.13 
1.2.19. Frame Relay 


Definition: A high-performance interface for packet-switching 
networks; considered more efficient that X.25. Frame relay 
technology can handle "bursty" communications that have rapidly 
changing bandwidth requirements. 


Discussion: None. 
Specification: FRF 
1.2.20. Frame Relay Frame 


Definition: A logical grouping of information sent as a link-layer 
unit over a transmission medium. Frame relay frames consist of a 
pair of flags, a header, a user data payload and a Frame Check 
Sequence (FCS). Bit stuffing differentiates user data bytes from 
flags. By default, the header is two octets, of which 10 bits are 
the Data Link Connection Identifier (DLCI), 1 bit in each octet is 
used for address extension (AE), and 1 bit each for Forward Explicit 
Congestion Notification (FECN), Backward Explicit Congestion 
Notification (BECN) Command/Response (C/R) and Discard Eligible (DE). 
The EA bit is set to one in the final octet containing the DLCI. A 
header may span 2, 3 or 4 octets. 


Dunn & Martin Informational [Page 9] 


RFC 3133 Terminology for Frame Relay Benchmarking June 2001 


Bit 7 6 5 4 3 2 1 0 


| User Data up to 
| 1600 Octets 


Discussion: Frame Relay headers spanning 3 or 4 octets will not be 
discussed in this document. Note, the measurements described later 
in this document are based on 2 octet headers. If longer headers are 
used, the metric values must take into account the associated 
overhead. See BECN, DE, DLCI and FECN. 


Specification: FRF 

1.2.21. Excess Information Rate (EIR) 
Definition: See Burst Excess. 
Discussion: None. 
Specification: FRF 

1.2.22. Network Interworking (FRF.5) 


Definition: FRF.5 defines a protocol mapping called Network 
Interworking between 


Frame Relay and Asynchronous Transfer Mode (ATM). Protocol mapping 
occurs when the network performs conversions in such a way that 
within a common layer service, the protocol information of one 
protocol is extracted and mapped on protocol information of another 
protocol. This means that each communication terminal supports 
different protocols. The common layer service provided in this 


Dunn & Martin Informational [Page 10] 


RFC 3133 Terminology for Frame Relay Benchmarking June 2001 


interworking scenario is defined by the functions, which are common 
to the two protocols. Specifically, the ATM terminal must be 
configured to interoperate with the Frame Relay network and vice 
versa. 


Discussion: None. 
Specification: FRF.5 
1.2.23. Port speed 
Definition: See Access Rate 
Discussion: None. 
Specification: FRF 
1.2.24. Service Interworking (FRF.8) 


Definition: FRF.8 defines a protocol encapsulation called Service 
Interworking. Protocol encapsulation occurs when the conversions in 
the network or in the terminals are such that the protocols used to 
provide one service make use of the layer service provided by another 
protocol. This means that at the interworking point, the two 
protocols are stacked. When encapsulation is performed by the 
terminal, this scenario is also called interworking by port access. 
Specifically, the ATM service user performs no Frame Relaying 
specific functions, and Frame Relaying service user performs no ATM 
service specific functions. 


Discussion: None. 
Specification: FRF.8 

1.2.25. Service Availability Parameters 
Definition: The service availability parameters report the 
operational readiness of individual frame relay virtual connections. 
Service availability is affected by service outages. 
Discussion: Service availability parameters provide metrics for 
assessment of frame relay network health and are used to monitor 


compliance with service level agreements. See Services Outages. 


Specification: FRF.13 
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1.2.26. Service Outages 


Definition: Any event that interrupts the transport of frame relay 
traffic. Two types of outages are differentiated: 


1) Fault outages: Outages resulting from faults in the network and 
thus tracked by the service availability parameters, and 


2) Excluded outages: Outages resulting from faults beyond the control 
of the network as well as scheduled maintenance. 


Discussion: Service availability can be defined on a per-VC basis 
and/or on a per-port basis. Frame relay port-based service 
availability parameters are not addressed in this document. See 
Service Availability Parameters. 
Specification: FRF.13 

2. Performance Metrics 

2.1. Definition Format (from RFC1242) 

Metric to be defined. 


Definition: The specific definition for the metric. 


Discussion: A brief discussion of the metric, its application and 
any restrictions on measurement procedures. 


Measurement units: Intrinsic units used to quantify this metric. 
This includes subsidiary units, e.g., microseconds are acceptable if 
the intrinsic unit is seconds. 

2.2. Definitions 

2.2.1. Physical Layer-Plesiochronous Data Hierarchy (PDH) 


2.2.1.1. Alarm Indication Signal (AIS) 


Definition: An all 1’s frame transmitted after the DTE or DCE detects 
a defect for 2.5 s +/- 0.5 s. 


Discussion: An AIS will cause loss of information in the PDH frame, 
which contains a frame relay frame which may contain IP datagrams. 


Measurement units: Dimensionless. 
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2.2.1.2. Loss of Frame (LOF) 
Definition: An NE transmits an LOF when an OOF condition persists. 


Discussion: A LOF will cause loss of information in the PDH frame, 
which contains a frame relay frame which may contain IP datagrams. 


Measurement units: Dimensionless. 
2.2.1.3. Loss of Signal (LOS) 


Definition: Indicates that there are no transitions occurring in the 
received signal. 


Discussion: A LOS will cause loss of information in the PDH frame 
which contains a frame relay frame which may contain IP datagrams. 


Measurement units: Dimensionless. 
2.2.1.4. Out of Frame (OOF) 
Definition: An NE transmits an OOF downstream when it receives 


framing errors in a specified number of consecutive frame bit 
positions. 


Discussion: An OOF will cause loss of information in the PDH frame 
which contains a frame relay frame which may contain IP datagrams. 


Measurement units: Dimensionless. 
2.2.1.5. Remote Alarm Indication (RAT) 


Definition: Previously called Yellow Alarm. Transmitted upstream by 
an NE to indicate that it detected an LOS, LOF, or AIS. 


Discussion: An RAI will cause loss of information in the transmitted 
PDH frame, which may contain a frame relay frame, which, in turn, may 
contain IP datagrams. 
Measurement units: Dimensionless. 

2.2.2. Frame Relay Layer 

2.2.2.1. Data Delivery Ratio (DDR) 
Definition: The DDR service level parameter reports the networks 


effectiveness in transporting offered data (payload without address 
field or FCS) in one direction of a single virtual connection. The 
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DDR is a ratio of successful payload octets received to attempted 
payload octets transmitted. Attempted payload octets transmitted are 
referred to as DataOffered. Successfully delivered payload octets 
are referred to as DataDelivered. These loads are further 
differentiated as being within the committed information rate or as 
burst excess. 
Three data relay ratios may be reported: 
Data Delivery Ratio (DDR): 

(DataDelivered_c + DataDelivered_e DataDelivered_etc 


(DataOffered_c + DataOffered_e) DataOffered_etc 


Data Delivery Ratio (DDR_c) for load consisting of frames within the 
committed information rate: 


DataDelivered_c 
DataOffered_c 


Data Delivery Ratio (DDR_e) for load in excess of the committed 
information rate: 


DataDelivered_e 
DataOffered_e 
where 


DataDelivered_c: Successfully delivered data payload octets within 
committed information rate, 


DataDelivered_e: Successfully delivered data payload octets in excess 
of CIR, 


DataDelivereD_et+c: Successfully delivered total data payload octets, 
including those within committed information rate and those in excess 


of CIR, 


DataOffered_c: Attempted data payload octet transmissions within 
committed information rate, 


DataOffered_e: Attempted data payload octet transmissions in excess 
of CIR 


and 
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DataOffered_etc: Attempted total data payload octet transmissions, 
including those within committed information rate and those in excess 
of CIR 


Each direction of a full duplex connection has a discrete set of data 
delivery ratios. 


Discussion: Data delivery ratio measurements may not be 
representative of data delivery effectiveness for a given 
application. For example, the discarding of a small frame containing 
an acknowledgement message may result in the retransmission of a 
large number of data frames. In such an event, a good data delivery 
ratio would be reported while the user experienced poor performance. 


Measurement units: dimensionless. 
2.2.2.2. Frame Delivery Ratio (FDR) 
Definition: The FDR service level parameter reports the networks 
effectiveness in transporting an offered frame relay load in one 
direction of a single virtual connection. The FDR is a ratio of 
successful frame receptions to attempted frame transmissions. 
Attempted frame transmissions are referred to as Frames Offered. 
Successfully delivered frames are referred to as Frames Delivered. 
These loads may be further differentiated as being within the 
committed information rate or as burst excess. 
Frame Delivery Ratio (FDR): 
Frame Delivery Ratio (FDR): 
(FramesDelivered_c + FramesDelivered_e) FramesDelivered_etc 
EDR- SS sSSs6S8- S55 SSeS ee ssesesSSSseS-= > = SARAR oS ee 
Frame Delivery Ratio (FDR_c) for load consisting of frames within the 
committed information rate: 
FramesDelivered_c 


FramesOffered_c 


Frame Delivery Ratio (FDR_c) for load in excess of the committed 
information rate: 


FramesDelivered_e 


FramesOffered_e 
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where 


FramesDelivered_c: Successfully delivered frames within committed 
information rate, 


FramesDelivered_e: Successfully delivered frames in excess of CIR, 


FramesDelivered_etc: Successfully delivered total frames, including 
those within committed information rate and those in excess of CIR, 


FramesOffered_c: Attempted frame transmissions within committed 
information rate, 


FramesOffered_e: Attempted frame transmissions in excess of CIR 
and 


FramesOffered_etc: Attempted total frame transmissions, including 
those within committed information rate and those in excess of CIR. 


An independent set of frame delivery ratios exists for each direction 
of a full duplex connection. 


Discussion: Frame delivery ratio measurements may not be 
representative of frame delivery effectiveness for a given 
application. For example, the discarding of a small frame containing 
an acknowledgement message may result in the retransmission of a 
large number of data frames. In such an event, a good data delivery 
ratio would be reported while the user 


Measurement units: dimensionless. 
2.2.2.3. Frame Discard Ratio (FDR) 


Definition: The number of received frames that are discarded because 
of a frame error divided by the total number of transmitted frames in 
one direction of a single virtual connection. Frame errors are 
defined as follows: 


frames that are too long or too short, 

frames that are not a multiple of 8 bits in length, 
frames with an invalid or unrecognized DLCI, 

frames with an abort sequence, 

frames with improper flag delimitation, 

frames that fail FCS. 


NOB WNE 
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The formal definition of frame discard ratio is as follows: 
sum {i=l to N} fr_i 
sum {i=l to N} ft_i, 

where 


fr_i is the number of successfully delivered frames for a particular 
DLCI at second i 


and 
ft_i is the total number of attempted frame transmissions within the 
committed plus extended information rate for a particular DLCI at 
second i. 
Discussion: Frame discards can adversely effect applications running 
on IP over FR. In general, frame discards will negatively impact TCP 
throughput; however, in the case of frame discard due to frame error, 
frame discard will improve performance by dropping errored frames. 
As a result, these frames will not adversely effect the forwarding of 
retransmitted frames 
Measurement units: dimensionless. 
2.2.2.4. Frame Error Ratio (FER) 

Definition: The number of received frames that contain an error in 
the frame payload divided by the total number of transmitted frames 
in one direction of a single virtual connection. 
The formal definition of frame error ratio is as follows: 

sum {i=l to N} fe_i 

sum {i=l to N} ft_i, 


where 


fe_i is the number of frames containing a payload error for a 
particular DLCI at second i 


and 
ft_i is the total number of attempted frame transmissions within the 


committed plus the extended information rate for a particular DLCI at 
second i. This statistic includes those frames which have an error 
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in the Frame Check Sequence (FCS). Frame errors in the absence of 
FCS errors can be detected by sending frames containing a known 
pattern; however, this indicates an equipment defect. 


Discussion: The delivery of frames containing errors will adversely 
effect applications running on IP over FR. Typically, these errors 
are caused by transmission errors and flagged as failed FCS frames; 
however, when Frame Relay to ATM Network interworking is used, an 
error may be injected in the frame payload which, in turn, is 
encapsulated into an AAL5 PDU (see RFC 2761 for a discussion of AAL5 
related metrics). 


Measurement units: dimensionless. 
2.2.2.5. Frame Excess Ratio (FXR) 

Definition: The number of frames received by the network and treated 
as excess traffic divided by the total number of transmitted frames 
in one direction of a single virtual connection. Frames which are 
sent to the network with DE set to zero are treated as excess when 
more than Bc bits are submitted to the network during the Committed 
Information Rate Measurement Interval (Tc). Excess traffic may or 
may not be discarded at the ingress if more than Bc + Be bits are 
submitted to the network during Tc. Traffic discarded at the ingress 
is not recorded in this measurement. Frames which are sent to the 
network with DE set to one are also treated as excess traffic. 
The formal definition of frame excess ratio is as follows: 

sum {i=l to N} fc_i 

sum {i=l to N} ft_i, 


where 


fc_i is the total number of frames which were submitted within the 
traffic contract for a particular DLCI at second i 


and 


ft_i is the total number of attempted frame transmissions for a 
particular DLCI at second i. 


Discussion: Frame discards can adversely effect applications running 
on IP over FR. Specifically, frame discards will negatively impact 


TCP throughput. 


Measurement units: dimensionless. 
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2.2.2.6. Frame Loss Ratio (FLR) 


Definition: The FLR is a ratio of successful frame receptions to 
attempted frame transmissions at the committed information rate, in 
one direction of a single virtual connection. Attempted frame 
transmissions are referred to as Frames Offered. Successfully 
delivered frames are referred to as Frames Delivered. 


The formal definition of frame loss ratio is as follows: 
FramesDelivered_c 
FramesOffered_c, 

where 


FramesDelivered_c is the successfully delivered frames within 
committed information rate for a given DLCI 


and 


FramesOffered_c is the attempted frame transmissions within committed 
information rate for a given DLCI 


An independent set of frame delivery ratios exists for each direction 
of a full duplex connection. 


Discussion: Frame delivery loss measurements may not be 
representative of frame delivery effectiveness for a given 
application. For example, the loss of a small frame containing an 
acknowledgement message may result in the retransmission of a large 
number of data frames. In such an event, a good data delivery ratio 
would be reported while the user 


Measurement units: dimensionless. 
2.2.2.7. Frame Policing Ratio (FPR) 


Definition: The number of frames received by the network and treated 
as excess traffic and dropped divided by the total number of received 
frames, in one direction of a single virtual connection. Frames 
which are sent to the network with DE set to zero are treated as 
excess when more than Bc bits are submitted to the network during the 
Committed Information Rate Measurement Interval (Tc). Excess traffic 
may or may not be discarded at the ingress if more than Bc + Be bits 
are submitted to the network during Tc. Traffic discarded at the 
ingress is recorded in this measurement. Frames which are sent to 
the network with DE set to one are also treated as excess traffic. 
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The formal definition of frame excess ratio is as follows: 
sum {i=l to N} fr_i 
sum {i=l to N} ft_i, 

where 


fr_i is the successfully delivered frames for a particular DLCI at 
second i 


and 


ft_i is the total number of attempted frame transmissions for a 
particular DLCI 


at second i. 


Discussion: Frame discards can adversely effect applications running 
on IP over FR. Specifically, frame discards will negatively impact 
TCP throughput. 


2.2.2.8. Frame Transfer Delay (FTD) 


Definition: The time required to transport frame relay data from 
measurement point 1 to measurement point 2. The frame transfer delay 
is the difference in seconds between the time a frame exits 
measurement point 1 and the time the same frame enters measurement 
point 2, in one direction of a single virtual connection. The formal 
definition of frame transfer delay is as follows: 


FTD = 1/N * sum {i=1 to N} t2_i - tli, 
where 


tl_i is the time in seconds when the ith frame leaves measurement 
point 1 (i.e., frame exit event), 


t2 is the time in seconds when the ith frame arrives at measurement 
point 2 (i.e., frame entry event) 


and 
N is the number of frames received during a measurement interval T. 
FTD is computed for a specific DLCI and a specified integration 


period of T seconds. The computation does not include frames which 
are transmitted during the measurement period but not received. 
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Discussion: While frame transfer delay is usually computed as an 
average and, thus, can effect neither IP nor TCP performance, 
applications such as voice over IP may be adversely effected by 
excessive FTD. 


Measurement units: seconds. 

2.2.2.9. Frame Transfer Delay Variation (FTDV) 
Definition: The variation in the time required to transport frame 
relay data from measurement point 1 to measurement point 2. The 
frame transfer delay variation is the difference in seconds between 
maximum frame transfer delay and the minimum frame transfer delay, in 
one direction of a single virtual connection. The formal definition 
of frame transfer delay is as follows: 

FTDV = max {i=l to N} FTD_i - min {i=1 to N} FTD_i. 

where 


FTD and N are defined as above. 


Discussion: Large values of FTDV can adversely effect TCP round trip 
time calculation and, thus, TCP throughput. 


Measurement units: seconds. 
3. Security Considerations 
As this document is solely for providing terminology and describes 


neither a protocol nor an implementation, there are no security 
considerations associated with this document. 


4. Notices 
Internet Engineering Task Force 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described 
in this document or the extent to which any license under such 
rights might or might not be available; neither does it represent 
that it has made any effort to identify any such rights. 
Information on the IETFs procedures with respect to rights in 
standards-track and standards-related documentation can be found 
in BCP-11. Copies of claims of rights made available for 
publication and any assurances of licenses to be made available, 
or the result of an attempt made to obtain a general license or 
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permission for the use of such proprietary rights by implementors 
or users of this specification can be obtained from the IETF 
Secretariat. 


The IETF invites any interested party to bring to its attention 
any copyrights, patents or patent applications, or other 
proprietary rights, which may cover technology that may be 
required to practice this standard. Please address the 
information to the IETF Executive Director. 


Frame Relay Forum 


Copyright Frame Relay Forum 1998. All Rights Reserved. 

References FRF, FRF.5, FRF.8 and FRF.13 and translations of them 
may be copied and furnished to others, and works that comment on 
or otherwise explain it or assist in their implementation may be 
prepared, copied, published and distributed, in whole or in part, 
without restriction of any kind, provided that the above copyright 
notice and this paragraph are included on all such copies and 
derivative works. However, these documents themselves may not be 
modified in any way, such as by removing the copyright notice or 
references to the Frame Relay Forum, except as needed for the 
purpose of developing Frame Relay standards (in which case the 
procedures for copyrights defined by the Frame Relay Forum must be 
followed), or as required to translate it into languages other 
than English. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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